昨天我們從實際要做的任務出發，整理了這次地端 Agent 希望具備的能力：

• 可以進行多輪對話
• 能夠理解圖片、PDF、Word、Excel 等不同類型的文件
• 可以操作電腦中的檔案，例如讀取、新增與修改檔案
• 可以協助產生或編輯 Word、Excel、PowerPoint
• 可以執行少量的網路搜尋
• 未來希望透過 Skill，逐步擴充 Agent 的能力
• 最重要的是，模型要能在手邊的設備上執行

有了需求，也大致知道該如何從 Benchmark 篩選模型後，下一個問題就是：

我們要怎麼把模型真正變成一個 Agent？

LLM 本身其實只負責「輸入 → 推論 → 輸出」。

如果今天希望它可以讀檔案、搜尋資料、呼叫程式、修改 Excel，甚至自己判斷下一步該使用哪一個工具，那我們還需要在模型外面建立一整套 Agent Runtime。

最簡單的 Agent Loop 大概可以寫成：

User
 ↓
LLM
 ↓
需要使用 Tool？
 ├─ Yes → 執行 Tool → 把結果交回 LLM
 └─ No  → 回覆使用者

看起來好像沒有很複雜。

真的要自己寫，當然也不是不行。

但問題通常不是出現在「第一次成功呼叫 Tool」，而是後面開始慢慢冒出來的需求。

例如：

Tool 呼叫失敗怎麼辦？
↓
要不要 Retry？

模型連續呼叫十幾次 Tool 怎麼管理？

對話太長超過 Context Window 怎麼辦？

Agent 執行到一半程式掛掉，
可以從上一個 Step 恢復嗎？

某些 Tool 執行前需要使用者確認怎麼辦？

不同 Agent 是否需要共享 State？

Skill 要什麼時候載入？

怎麼記錄每一次 Tool Call？

怎麼知道 Agent 到底在哪一步出錯？

寫到這裡，就會慢慢發現：

我們原本只是想寫一個 Agent，最後卻開始自己寫 Agent Framework。

這也是為什麼這次我會先 Survey 現有的開源 Agent Framework，再決定哪些東西值得自己做。

為什麼要使用 Agent Framework？

Agent Framework 最主要的價值，不是幫我們呼叫 LLM。

這件事情其實很簡單。

真正有價值的是，它幫我們處理 Agent 外圍大量重複出現的基礎設施，例如：

Model
 │
 ▼
Agent Loop
 │
 ├── Tool Calling
 ├── State
 ├── Memory
 ├── Retry
 ├── Context Management
 ├── Skill
 ├── MCP
 ├── Human in the Loop
 ├── Sub-Agent
 └── Observability

如果這些功能全部自己實作，不只是開發時間增加，後續維護成本也會快速變高。

尤其這次我的目標並不是研究「如何從零打造一個 Agent Framework」，而是希望把時間放在更重要的問題：

地端模型搭配 Agent Framework 與 Skill，到底能不能完成真正有用的日常工作？

因此使用既有框架，可以讓我們把注意力放回真正想驗證的事情。

使用 Framework 有什麼優點？

第一個優點當然就是 少造很多輪子。

像 Tool Calling、Conversation State、Context Management、Retry、Checkpoint 等能力，在成熟框架中通常都已經有相對完整的實作。

第二個優點是 架構會比較容易擴充。

今天可能只有：

filesystem
search
python

三個 Tools。

但未來可能變成：

filesystem
search
python
Excel
Word
PowerPoint
Database
Browser
MCP Server
ERP
MES

如果一開始完全自己把 Agent Loop 寫死，後面會越來越難維護。

另外一個很重要的優點是 可觀測性。

當 Agent 任務開始變長時，我會希望知道：

模型思考了幾次？
呼叫哪些 Tool？
哪一步失敗？
花多少時間？
用了多少 Token？
Retry 幾次？
最後為什麼得到這個答案？

這些對玩具型 Agent 可能不是問題。

但如果未來希望 Agent 真正進入企業環境，這些幾乎都會變成必要條件。

那 Framework 有沒有缺點？

當然有。

而且這也是我這次不打算直接選最熱門框架就結束的原因。

第一個問題是 抽象層越多，越容易不知道底層發生什麼事情。

原本可能只是：

while True:
    response = model(...)

導入 Framework 後可能變成：

Agent
→ Middleware
→ Runtime
→ Graph
→ Tool Executor
→ Model Adapter
→ Provider

發生問題時，Debug 難度不一定比較低。

第二個問題是 框架會帶來自己的設計哲學。

例如有些框架非常強調：

Graph / Workflow

有些則強調：

Multi-Agent

有些是：

Agent Harness

還有一些更偏向：

Coding Agent

如果自己的需求跟框架原本的設計方向不同，就很容易變成：

為了使用 Framework，開始把自己的需求硬塞進 Framework。

這反而本末倒置。

第三個問題則是 Vendor / Framework Lock-in。

Agent 生態目前變化非常快。

今天熱門的 Library，半年後可能 API 已經完全不同，甚至整個專案方向都可能改變。

因此這次我挑框架時，除了功能之外，也會特別觀察：

• 是否仍持續維護
• 最近是否仍有 Release
• 社群與文件是否完整
• 能不能接 Local LLM
• Tool / Skill 是否容易自行擴充
• 是否能避免把整套系統綁死在特定模型供應商

那現在有哪些 Agent Framework？

我先從目前仍持續開發、而且和這次需求比較相關的開源專案開始 Survey。

這並不是所有 Agent Framework 的完整清單，而是我初步篩選後認為比較值得繼續研究的一批。

LangGraph

LangChain 團隊推出的低階 Agent orchestration framework。

它的核心特色是用 Graph 與 State 控制 Agent 執行流程，非常適合需要 Branch、Retry、Checkpoint、Human-in-the-loop 與可追蹤流程的 Agent 系統。目前 LangGraph 仍持續推出新版本，例如 2026 年 8 月仍發布 LangGraph 1.2.x 與 SDK 更新。

Deep Agents

同樣來自 LangChain 生態，但定位和 LangGraph 不太一樣。

Deep Agents 是一個更高階、較 opinionated 的 Agent Harness，底層使用 LangGraph Runtime，已經幫我們整合 Agent 建構、Skills、Sub-agent、Filesystem 與 Context Management 等能力，因此比直接從 LangGraph 開始更接近「拿來直接做 General Agent」。

Hermes Agent

Nous Research 開源的完整 Agent 系統，方向偏向 Personal Agent / Autonomous Agent。

除了 Tool、Skill、Memory、MCP 外，也包含 Browser、Desktop、Sub-agent、排程等功能，而且近幾個月仍維持非常高頻率的更新；截至 2026 年 9 月仍持續發布新版本。

Pi

Pi 的方向和前面幾個 Framework 很不一樣。

它是一個刻意保持核心很小的 Terminal Coding Harness，只提供必要能力，再透過 Skills、Extensions、Prompt Templates 與 Packages 自行擴充。Pi 甚至刻意不把 MCP、Sub-agent、Plan Mode 等功能全部塞進核心，而是希望開發者依需求自行組裝。

smolagents

Hugging Face 推出的輕量 Agent Framework。

最大的特色是除了傳統 Tool Calling Agent 外，還有 CodeAgent 的設計，讓模型可以透過產生 Python Code 來組合工具與處理任務，而不是每一個步驟都必須再進行一次 Tool Calling。

Pydantic AI

由 Pydantic 團隊開發的 Agent Framework，特別強調 Type-safe、Structured Output 與 Production Application。

如果本來就習慣 Python、Pydantic 與明確的資料模型，這套 Framework 會非常自然，而且目前開發相當活躍，2026 年 9 月仍持續密集發布新版本。

Microsoft Agent Framework

Microsoft 新一代的 Agent Framework，主要定位在 Production-grade Agent 與 Multi-Agent Workflow。

它同時支援 Python、.NET，並提供 Agent、Workflow、Tool、Skills、MCP 等能力，方向明顯偏向企業環境與正式部署。

CrewAI

CrewAI 主打 Role-based Multi-Agent。

概念上可以把不同 Agent 定義成 Researcher、Analyst、Writer、Reviewer 等角色，再讓不同角色協作完成任務；如果需求本身就是典型的多人分工流程，CrewAI 的抽象會非常直觀。

CAMEL

CAMEL 比較偏 Multi-Agent Research 與 Agent Society。

除了 Task Automation，也涵蓋多 Agent Simulation、Synthetic Data 與不同 Agent 行為研究，因此如果未來要測試大量 Agent 間的互動，它會比一般單 Agent Framework 更有研究價值。

Browser Use

Browser Use 嚴格來說比較不像完整的 General-purpose Agent Framework，而是專門解決 Browser Agent 的問題。

它提供瀏覽器操作、頁面理解與 Agent Tooling，並持續整合 MCP 等能力；2026 年 9 月仍有新版本發布。

因此它未來比較有可能是：

Agent Framework
      +
Browser Use

而不是兩者二選一。

所以到底要選哪一套？

目前還不急著下結論。

經過第一輪 Survey 後，我比較在意的其實不是「哪一套功能最多」，而是：

哪一套架構最符合我要打造的地端 Agent？

以目前需求來看，我會優先關注幾個方向：

Local LLM
+
Skill
+
Tool
+
Filesystem
+
文件處理
+
長任務
+
可追蹤
+
可以自己擴充

第一輪評估後，我目前給出最高適合度的幾個框架是：

Deep Agents     
Hermes Agent    
LangGraph       
Pi              
smolagents      

但有趣的是——

這五套其實不是在解決完全相同的問題。

LangGraph 比較像 Agent Runtime / Orchestration。

Deep Agents 比較像完整 Agent Harness。

Hermes 已經非常接近一套可以直接使用的 Autonomous Agent。

Pi 則刻意保持一個非常小、非常乾淨的 Agent Harness。

smolagents 又走向另一條路，嘗試讓 Agent 直接使用 Code 來完成 Action。

所以接下來如果只是做一張：

「五套 Agent Framework 功能比較表」

其實會漏掉很多真正重要的差異。

接下來幾天，我打算把這幾個目前拿到滿分的候選框架逐一拆開。

看看它們到底怎麼設計 Agent Loop、Tool、Skill、Memory、Context Management，以及它們各自怎麼面對 Local LLM。

最後再把同一批模型、同一組任務放進不同 Agent Framework 裡實際跑看看。

到了那個時候，我們應該就可以回答一個比：

「哪一套 Agent Framework 最紅？」

更實際的問題：

「哪一套 Agent Framework，真的適合拿來打造我們這台地端 Agent？」